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There  Is  a  pressing  need  to  make  software  system  acquisition  more  agile  and 
adaptive,  through  evolutionary  modeling,  simulation,  and  developmentof  the 
system  being  acquired.  Here  we'll  describe  a  new  vision  forthe  re-tooling  and 
reengineering  software  system  acquisition  into  a  form  we  call  VISTA,  denoting 
an  approach  to  the  virtual  acquisition  of  these  systems.  We  will  describe  this 
new  approach,  and  then  discuss  the  technical  and  organizational  transitions 
that  must  be  investigated  and  managed  to  ensure  the  eventual  success  of 
such  a  radical  change  to  software  system  acquisition. 


The  acquisition  of  major  software-in¬ 
tensive  systems  is  often  problematic. 
Recent  reports  from  the  U.S.  Gen¬ 
eral  Accounting  Office  (GAO,  1995; 
GAO,  1997)  describe  a  number  of  prob¬ 
lems  with  the  way  complex  systems  are 
acquired.  The  current  acquisition  prob¬ 
lems  include: 

•  difficulty  in  establishing  viable  and 
cost-effective  system  requirements; 

•  overly  optimistic  cost,  schedule,  and 
performance  estimates; 

•  concurrent  development  and  produc¬ 
tion  of  systems;  and 

•  commitment  to  system  production  be¬ 
fore  adequate  demonstration  or  testing 
that  determines  system  viability  is 
completed. 


To  no  one’s  surprise,  modern  and  fu¬ 
ture  weapon  systems  increasingly  repre¬ 
sent  software-intensive  systems.  In  addi¬ 
tion,  the  Department  of  Defense  (DoD) 
and  other  government  agencies  rely  on  the 
acquisition  and  use  of  computer-based 
information  systems  to  manage  their  re¬ 
curring  organizational  and  operational 
activities.  Many  of  these  management  in¬ 
formation  systems  are  often  running  on 
outdated  computing  platforms  that  must 
be  replaced  or  modernized. 

The  DoD  has  established  acquisition 
strategies  that  move  it  toward  commercial 
acquisition  practices.  One  strategy  embod¬ 
ies  the  idea  that  the  feasibility  and  ability 
to  produce  advanced  technologies  can  of¬ 
ten  be  demonstrated  before  they  are  in¬ 
corporated  into  acquisition  programs.  For 
example,  the  use  of  advanced  concept 
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Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 
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technology  demonstrations  can  more  di¬ 
rectly  involve  war  fighters  and  users  in 
demonstrating  the  operational  feasibility 
of  new  technologies  and  concepts  before 
commitments  are  made  to  full-scale  ac¬ 
quisition.  Another  strategy  rooted  in  the 
Defense  Acquisition  Workforce  Improve¬ 
ment  Act  (DAWIA)  establishes  bench¬ 
marks  for  a  more  professional  acquisition 
workforce  with  defined  training  and  edu¬ 
cation  requirements,  and  acquisition  ca¬ 
reer  paths.  The  goal  of  this  act  is  to  pro¬ 
vide  an  acquisition  workforce  that  is  more 
responsible  for  improving  program  costs 
and  schedule  estimates.  Finally,  in  1994 
the  Office  of  the  Secretary  of  Defense 
began  pursuing  a  strategy  to  reengineer 
the  systems  acquisition  review  process. 
This  includes  an  effort  to  reduce  acquisi¬ 
tion  costs  (including  overhead  costs) 
through  the  adoption  of  business  processes 
characteristic  of  world-class  commercial 
buyers  and  suppliers. 

The  overall  way  in  which  the  federal 
government  conducts  its  acquisition  prac¬ 
tices  has  been  reviewed  and  redesigned 
in  response  to  the  Federal  Acquisition 
Streamlining  Act  (FAS  A)  of  1994.  Among 
other  things,  the  FAS  A  requires  incentives 
and  a  performance-based  approach  to 


managing  acquisition  programs.  This  em¬ 
phasizes  streamlining  the  acquisition  pro¬ 
cess  and  proposes  greater  reliance  on  com¬ 
mercial  products  and  processes.  Also,  con¬ 
cepts  for  applying  commercial  practices 
to  DoD  software  system  acquisition  have 
been  addressed  in  Defense  Science  Board 
reports. 

Thus,  we  are  at  a  time  when  there  is 
substantial  opportunity  to  rethink  how  the 
acquisition  of  software-intensive  systems 
should  occur  to  address  the  recurring  prob¬ 
lems.  At  the  same  time,  we  should  pursue 
new  opportunities  to  reengineer  the  sys¬ 
tems  acquisition  process  that  can  realize 
savings,  efficiencies,  increased  satisfac¬ 
tion,  and  continuous  improvement.  Simi¬ 
larly,  we  should  provide  a  strategy  for 
managing  the  transition  to  these 
reengineered  system  acquisition  pro¬ 
cesses,  as  they  can  represent  a  radical  de¬ 
parture  from  current  practices.  Subse¬ 
quently,  we  seek  to  explore  how  these 
opportunities  can  be  pursued  through  use 
of  advanced  information  processing  tools, 
techniques,  and  concepts.  Our  objective 
is  to  make  the  acquisition  of  software-in¬ 
tensive  systems  more  agile  and  adaptive. 
Relevant  information  technologies  include 
those  for: 
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•  re-tooling  system  acquisition  processes 
to  better  assess  the  feasibility  of  sys¬ 
tem  acquisitions; 

•  digital  libraries  for  organizing  and  shar¬ 
ing  information  gathered  during  sys¬ 
tem  acquisitions  and  program  manage¬ 
ment;  and 

•  Internet-based  electronic  commerce 
services  and  capabilities  for  streamlin¬ 
ing  procurement  actions,  lead  times, 
and  supply  chain  logistics  (Nissen, 
1997;  Scacchi  and  Noll,  1997,  Scacchi, 
et  al,  1997). 

However,  in  this  paper  and  in  related 
materials  (Boehm  and  Scacchi,  1996),  we 
focus  our  discussion  on  the  first  of  these 
areas. 

Steps  Toward  More  Agile 
Acouisition  of  Future  Systems 


In  general  terms,  our  overall  goal  is  to 
address  the  recurring  problems  that  plague 
system  acquisition  efforts.  Our  approach 
suggests  ways  in  which  new  modeling  and 
simulation  techniques  can  help  in 
reengineer  software-intensive  systems 
acquisition  by  the  DoD  and  other  govern¬ 
ment  agencies.  This  means  that  we  seek 
to  identify  new  concepts,  tools,  and  tech¬ 
niques  for  acquiring  software-intensive 
systems  that  fulfill  four  goals:  First,  to 
establish  viable  and  cost-effective  system 
requirements.  Second,  to  establish  realis¬ 
tic  cost,  schedule,  and  performance  esti¬ 
mates.  Third,  to  mitigate  against  concur¬ 
rent  development  and  production  of  sys¬ 
tems.  Fourth,  to  enable  adequate  demon¬ 
stration  and  testing  of  system  viability 


before  a  commitment  to  system  produc¬ 
tion  must  be  made.  Based  on  the  results 
from  a  series  of  workshops  and  Blue  Rib¬ 
bon  Panels  of  leading  military,  industry, 
and  academic  experts  that  addressed  the 
problems  of  large-scale  software  system 
acquisition  (Boehm  and  Scacchi,  1996), 
we  can  identify  five  issues  involved  in 
achieving  the  overall  goal. 

First,  we  need  to  baseline  our  current 
understanding  of  strengths  and  weak¬ 
nesses  of  cur¬ 
rent  “as-is”  pro¬ 
cess  capabilities 
for  acquiring 
software-inten¬ 
sive  systems. 

Guidelines,  best 
practices,  and 
lessons  learned 
are  being  col¬ 
lected  and  dis¬ 
seminated.  The  Software  Technology  Sup¬ 
port  Center  (STSC,  1995)  and  the  Soft¬ 
ware  Program  Managers  Network 
(SPMN,  1997)  have  assembled  recent  col¬ 
lections.  Nonetheless,  we  also  need  to 
understand  how  they  are  employed,  and 
to  identify  the  operational  problems  that 
may  inhibit  their  application  and  success. 

Next,  we  need  to  develop  scenarios  for 
new  “to-be”  acquisition  process  capabili¬ 
ties  that  exploit  an  evolutionary  “virtual” 
approach  to  the  acquisition  of  software¬ 
intensive  systems.  Such  an  approach  em¬ 
phasizes  the  incremental  acquisition  of 
virtual  prototypes  for  a  new  software-in¬ 
tensive  system.  These  prototypes  start  as 
models  of  the  intended  system.  These  sys¬ 
tem  models  can  be  analyzed  and  simulated 
to  determine  which  system  requirements 
and  risks  have  been  addressed.  As  famil¬ 
iarity  and  confidence  with  the  prototypes’ 


" First,  we  need  to 
baseline  our  current 
understanding  of 
strengths  and  weak¬ 
nesses  of  current 
"as-is"  process 
capabilities  for 
acquiring  software¬ 
intensive  systems." 
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increases,  their  realism  and  functionality 
increases  with  the  incremental  integration 
of  system  components.  In  this  way,  vir¬ 
tual  prototypes  of  systems  can  he  incre¬ 
mentally  modeled  and  iteratively 
reconfigured  with  simulated  or  actual  sub¬ 
system  compo¬ 
nents.  The  de¬ 
velopment  and 
production  of  a 
growing  num¬ 
ber  of  complex 
electro-me¬ 
chanical  assem¬ 
blies  are  now 
designed, 
tested,  and  re¬ 
fined  through  the  use  of  computational 
models  and  simulations  as  virtual  pro¬ 
totypes  (Garcia,  Gocke,  and  Johnson, 
1994). 

Similarly,  the  availability  of  Battle  Labs 
suggests  the  use  of  virtual  battlefields  and 
command  centers  for  trying  out  or  exer¬ 
cising  complex  defense  systems  in  alter¬ 
native  scenarios,  through  computer-based 
modeling  and  simulation  test-beds  oper¬ 
ating  within  networked  laboratories 
(Cothran,  1996;  Wilson  1996).  Accord¬ 
ingly,  approaches  such  as  these  may  also 
prove  to  be  effective  in  supporting  the 
acquisition  of  software  systems.  In  this 
way,  viability  and  cost-effectiveness  of 
system  requirements  can  be  demonstrated, 
validated,  and  refined  in  an  incremental 
manner.  Similarly,  estimates  for  the  cost, 
schedule,  and  performance  of  an  ever- 
more-complete  actual  system  can  also  be 
developed  and  refined  incrementally.  Sub¬ 
sequently,  we  should  also  consider  devel¬ 
oping  methods  and  scenarios  for  how  to 
shift  from  the  “as-is”  to  the  “to-be”  ac¬ 
quisition  process  we  envision. 


Third,  we  need  to  articulate  the  design 
and  operational  concept  for  a  wide-area 
modeling  and  simulation  infrastructure 
that’s  primary  purpose  is  to  serve  as  a  test¬ 
bed  and  delivery  platform  for  agile  acqui¬ 
sition  of  software-intensive  systems.  Such 
an  infrastructure  may  need  to  support  col¬ 
laboration  and  resource  sharing  between 
software  system  researchers  and  develop¬ 
ers  at  geographically  distributed  sites.  It 
may  operate  as  a  modeling  and  simula¬ 
tion  collaboratory  (Kouzes,  Meyers,  and 
Wulf,  1996)  for  software  system  acquisi¬ 
tion.  Similarly,  such  an  infrastructure  may 
need  to  support  a  hypermedia  repository 
or  digital  library  of  technical  data  and  in¬ 
formation  that  can  be  accessed  and  shared 
over  the  Internet  or  World  Wide  Web 
(WWW).  Such  a  digital  library  should 
store  and  organize  access  to  software  ac¬ 
quisitions  assets.  These  may  include  pub¬ 
lications,  model  and  simulation  libraries, 
reusable  software  subsystem  components, 
system  demonstration  scenarios,  multime¬ 
dia  presentations  and  annotations.  In  ad¬ 
dition,  the  digital  library  may  provide 
paths  to  super  computing  environments 
that  support  massively  parallel  simula¬ 
tions,  etc. 

We  also  want  to  understand  how  future 
acquisition  processes  or  capabilities  might 
exploit  the  full  range  of  technology  strat¬ 
egies  and  options  at  hand.  The  goal  is  to 
minimize  cost,  maximize  customer  satis¬ 
faction  (via  system  performance  and  qual¬ 
ity  attributes)  and  minimize  acquisition 
and  development  cycle  time.  Relevant 
technologies  that  can  support  this  goal 
include  the  use  of  knowledge-based  sys¬ 
tems,  multimedia,  the  Internet,  electronic 
commerce  for  selling  and  buying  software 
components,  architecture-based  software 
system  development,  high-performance 


"The  goal  is  to 
minimize  cost,  maxi 
mize  customer  satis 
faction  (via  system 
performance  and 
quality  attributes) 
and  minimize  acqui 
sition  and  develop¬ 
ment  cycle  time." 
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computing  and  communications,  etc.  Will 
new  modes  of  academic  research  or  in¬ 
dustrial  activity  be  required  to  most  effec¬ 
tively  support  agile  acquisition?  If  so,  what 
are  they?  Similarly,  what  institutional  or 
marketplace  incentives  are  needed  to  help 
make  them  happen? 

Finally,  we  need  to  set  priorities  and 
estimate  the  relative  costs  and  benefits  of 
candidate  investments  in  modeling  and 
simulation  capabilities  that  support  soft¬ 
ware  system  acquisition.  We  need  to  iden¬ 
tify  areas  in  which  needs  can  be  met 
largely  through  available  technology.  And 
we  must  identify  areas  in  which  acquisi¬ 
tion  research  and  the  development  of  au¬ 
tomated  acquisition  support  environments 
promise  an  attractive  return-on-invest- 
ment. 


Background  and  Foreground 


We  may  now  be  at  the  threshold  of  a 
new  era  in  the  acquisition  and  develop¬ 
ment  of  software-intensive  systems.  From 
this  point,  we  can  look  back  to  where  we 
have  been  and  what  we  have  experienced. 
Then  we  can  look  forward  toward  the  ho¬ 
rizon  to  see  what  lies  ahead. 

Looking  Back:  Why  Use  Models  and 
Simulations  TO  Support  Program 
Acquisitions 

In  looking  back,  we  see  that  the  acqui¬ 
sition  and  development  of  software-inten¬ 
sive  systems  was  guided  by  the  classic 
“waterfall”  system  life  cycle.  In  such  an 
approach,  DoD  customers  were  expected 
to  be  able  to  articulate  their  needs  and  re¬ 
quirements  for  new  system  capabilities 
prior  to  system  development.  Developers 


or  contractors  could  then  take  these  re¬ 
quirements  as  their  starting  point.  Then 
they  would  systematically  develop,  test, 
and  deliver  results  to  the  customer  accord¬ 
ing  to  a  sequence  of  development  mile¬ 
stones  and  documentation  standards. 

While  this  approach  has  much  rational 
appeal,  its  practice  and  outcome  has  of¬ 
ten  been  less 
than  satisfac¬ 
tory.  The  over¬ 
all  experience 
was  that  it  was 
difficult  for  cus¬ 
tomers  to  fully 
articulate  their 
system  require¬ 
ments  prior  to 
the  beginning  of 
system  devel¬ 
opment.  Furthermore,  when  system  devel¬ 
opment  took  years,  the  customer  (and  the 
developer)  recognized  their  requirements 
were  changing,  sometimes  very  rapidly. 
Consequently,  far  too  many  systems  de¬ 
veloped  under  contract  were  delivered  that 
did  not  meet  critical  system  requirements. 
In  the  worst  cases,  the  software  systems 
were  effectively  nonoperational.  Subse¬ 
quently,  more  customers  and  developers 
began  to  recognize  that  perhaps  these 
shortfalls  in  software  acquisition  and  de¬ 
velopment  were  systemic,  rather  than  sim¬ 
ply  characteristic  of  particular  programs 
or  development  organizations. 

In  response  to  the  seemingly  inevitable 
shortfalls  with  the  classic  approach,  efforts 
to  find  an  alternative  began.  This  led  to 
an  incremental  “spiral”  development  ap¬ 
proach.  In  the  classic  approach,  there  is 
little  visibility  regarding  operational  soft¬ 
ware  system  capabilities  until  late  in  the 
development  cycle.  In  contrast,  the  spiral 


" ...we  need  to  set 
priorities  and  esti¬ 
mate  the  relative 
costs  and  benefits  of 
candidate  invest¬ 
ments  in  modeling 
and  simulation 
capabilities  that 
support  software 
system  acquisition." 
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approach  embraces  a  more  evolutionary 
and  iterative  development  model.  Accord¬ 
ingly,  operational  software  capabilities 
become  visible  in  evolutionary  incre¬ 
ments,  rather  than  all  at  once.  Subsequent 
development  iterations  then  add  and  inte¬ 
grate  more  increments  until  the  final  sys¬ 
tem  is  ready. 
Thus  the  spiral 
approach  seeks 
to  build  and  de¬ 
liver  software¬ 
intensive  sys¬ 
tems  through 
evolutionary 
development. 
Consequently, 
guidelines  now 
put  forth  in  military  or  public  standards 
such  as  MIL-STD-498,  ANSI  J-STD-016, 
and  US  12207  encourage  use  of  an  incre¬ 
mental  spiral  approach  when  acquiring 
and  developing  software  intensive  sys¬ 
tems. 

Why  should  we  use  models  and  simu¬ 
lations  to  support  the  incremental  acqui¬ 
sition  of  complex  software  systems?  In 
simplest  terms,  we  can  identify  three  rea¬ 
sons:  First,  to  facilitate  early  identifica¬ 
tion  and  reduction  of  risks  associated  with 
complex  system  acquisition  programs. 
Second,  to  better  understand  what  kinds 
of  system  requirements  and  architectures 
are  feasible  and  affordable  given  various 
programmatic  and  technological  con¬ 
straints.  Third,  to  gain  insight  into  how  to 
better  manage  the  system  engineering  ef¬ 
fort  so  as  to  improve  the  overall  likelihood 
of  a  successful  acquisition  effort. 

But  the  creation,  use,  and  reliance  of 
models  and  simulations  to  support  incre¬ 
mental  acquisition  efforts  cannot  guaran¬ 
tee  such  outcomes.  Clearly,  models  and 


simulations  of  complex  systems  will  never 
be  more  than  assumption-laden  approxi¬ 
mations  of  the  systems  being  acquired. 
This  is  the  fate  of  all  models  and  simula¬ 
tions  (Smith,  1996).  Nonetheless,  the  pro¬ 
cess  of  building,  using,  and  evolving  such 
models  and  simulations  in  support  of  de¬ 
cision-making  activities  in  large  system 
acquisition  efforts  can  be  characterized  as 
one  of  consensus  validation  (Dutton  and 
Kraemer,  1985).  Thus,  the  value  of  sup¬ 
porting  system  acquisition  through  mod¬ 
eling  and  simulation  will  be  found  in  the 
process  of  working  with  them,  rather  than 
in  the  calculations  performed  along  the 
way.  Modeling  and  simulation  can  be  used 
to  help  identify  where  consensus  can  be 
established  and  validated,  as  well  as  to 
identify  where  disagreements  can  be 
found,  so  their  consequences  can  be  ex¬ 
amined. 

Program  managers,  contractors,  cus¬ 
tomers,  and  acquisition  directorate  staff 
can  use  models  and  simulations  coordi¬ 
nated  by  a  negotiation  support  system. 
Such  a  system  can  support  the  elicitation, 
capture,  and  validation  of  points  of  agree¬ 
ment  among  system  acquisition  partici¬ 
pants.  In  addition,  such  a  system  can  help 
these  people  surface  assumptions,  debate 
their  merits  or  implications,  and  negoti¬ 
ate  alternative  system  configurations  and 
functional  features  (Boehm  et  al.,  1995). 
In  this  manner,  computer-based  models 
and  simulations,  together  with  an  infor¬ 
mation  sharing  and  negotiation  support 
environment,  provide  a  more  articulate 
medium  to  express  opinions  and  stimu¬ 
late  alternative  conceptions  of  system  ac¬ 
quisition  problems  and  challenges.  With¬ 
out  such  articulate  models  and  simula¬ 
tions,  system  acquisition  participants 
are  left  to  their  private  intuitions  and 


"Program  managers, 
contractors,  custom¬ 
ers,  and  acquisition 
directorate  staff  can 
use  models  and 
simulations  coordi¬ 
nated  by  a  negotia¬ 
tion  support  sys¬ 
tem." 
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conceptions  of  system  design,  program 
cost  drivers,  and  the  like.  This  in  turn  can 
easily  obscure  problems  in  system  design 
or  performance,  increase  the  likelihood  of 
miscommunication  and  systemic  conflict, 
and  increase  the  likelihood  of  problem¬ 
atic  system  acquisition  and  costly  post-de¬ 
ployment  support  of  the  resulting  systems. 
Thus,  we  believe  that  models,  simulations, 
and  associated  environments  can  play  a 
significant  role  in  supporting  the  incre¬ 
mental  acquisition  of  complex  software 
systems. 

Looking  Ahead:  An  Emerging  Case  Study 

We  see  many  opportunities  for  improv¬ 
ing  the  effectiveness  and  responsiveness 
of  the  acquisition  of  software-intensive 
systems  across  their  life  cycle.  Many  of 
these  opportunities  result  from  the  avail¬ 
ability  of  new  technologies  and  develop¬ 
ment  capabilities  that  make  the  acquisi¬ 
tion  of  software-intensive  system  more 
agile.  Agility  can  lead  to  more  cost-ef¬ 
fective,  more  timely,  and  higher  quality 


results  in  software  system  acquisition. 
Modeling  and  simulation  technologies  that 
support  virtual  prototyping  (Garcia, 
Gocke,  and  Johnson,  1994)  and  simula¬ 
tion-based  design  of  complex  hardware 
systems  are  being  used  to  support  major 
program  acquisitions,  such  as  that  for  the 
SC-21  class  of  battleships  (SC-21, 1997). 
We  believe  a  similar  effort  is  appropriate 
for  acquisition  of  the  large  software  sys¬ 
tems  associated  with  such  hardware  sys¬ 
tems.  Accordingly,  by  examining  the  cur¬ 
rently  proposed  software  systems  intended 
to  support  SC-21 -class  ships,  we  can  bet¬ 
ter  motivate  and  articulate  a  vision  for  how 
new  modeling  and  simulation  technolo¬ 
gies  can  be  used  to  help  support  the  incre¬ 
mental  acquisition  of  complex  software 
systems. 

There  is  no  single  architecture  or  final 
design  envisioned  for  SC-21  ships.  In¬ 
stead,  the  SC-2 1  ships  could  be  built  fol¬ 
lowing  the  commercial  practice  of  devel¬ 
oping  a  product  line  with  common  sub¬ 
systems  or  reusable  designs.  Figure  1 


Figure  1.  Alternative  Overall  Architectures  for  SC-21  Ships 

(SC-21,  1997) 
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helps  show  what  this  means.  Here  we  see 
four  alternative  views  of  the  overall  ar¬ 
chitecture  of  SC-21  ships.  The  intent  to 
enable  the  choice  of  the  final  architecture 
of  each  ship  to  he  determined  hy  emerg¬ 
ing  need  or  threat.  Nonetheless,  any  such 
SC-2 1  ship  will  still  have  some  configu¬ 
ration  of  common  subsystems  for  weap¬ 
ons,  command  deck,  flight  operations,  etc. 
As  such,  all  of  the  alternative  versions  of 
ship  architecture  displayed  in  Figure  1 
would  be  members  of  the  SC-21  product 
line. 

Building  these  ships  according  to  dif¬ 
ferent  architectural  configurations  repre¬ 
sents  a  fundamental  change  in  how  such 
ships  will  be  acquired,  developed,  and 
operated.  The  system  life  cycle  for  these 


ships  will  be  iterative,  incremental,  and 
ongoing.  Figure  2  conveys  a  vision  for 
how  various  computer-based  modeling 
and  simulation  technologies,  such  as  vir¬ 
tual  weapon  system  modeling  and  simu¬ 
lation-based  design,  may  be  employed  to 
support  the  acquisition,  development,  and 
operation  of  SC-2 1  ships. 

SC-21  ships  will  be  software-intensive 
systems.  All  major  subsystems  and  over¬ 
all  system  capabilities  supporting  each 
ship’s  operations  depend  on  software.  Fig¬ 
ure  3  proposes  a  suggested  allocation  of 
shipboard  subsystem  capabilities  that  will 
be  implemented  in  software  systems.  To¬ 
tal  number  of  software  instructions  or 
source  lines  of  code  (SLOC)  to  realize  the 
proposed  capabilities  is  estimated  at 


Figure  2.  Vision  for  How  Modeling  and  Simulation  Can  Support  New 
System  Acquisition  and  Development  (SC-21,  1997) 
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greater  than  8.4  million  SLOC.  Much  of 
this  software  can  potentially  he  reused 
across  the  SC-21  line  of  ships,  however. 
Nonetheless,  development  costs  for  soft¬ 
ware  of  this  size  and  complexity  is  often 
estimated  in  the  range  of  $100  million  to 
$1  billion.  Thus,  what  can  he  done  to  help 
understand  the  feasibility  of  alternative 
software  subsystem  architectures  associ¬ 
ated  with  the  SC-21  ship  family,  and  man¬ 
age  the  progress,  costs,  and  risks  associ¬ 
ated  with  the  acquisition  and  development 
of  this  software? 

At  present,  there  is  an  emerging  con¬ 
sensus  for  what  technological  capabilities 
are  needed  to  support  the  acquisition  and 
development  of  software-intensive  sys¬ 
tems  such  as  the  family  of  SC-21  ships 


(Boehm  and  Scacchi,  1996).  Much  like  the 
SC-21  family  of  ship  hardware  and  ma¬ 
jor  subsystems  employs  recent  advances 
in  modeling  and  simulation  technologies, 
similar  technologies  could  be  brought  to¬ 
gether  to  support  the  acquisition  and  de¬ 
velopment  of  the  software  systems  for 
these  ships.  Accordingly,  we  can  now  out¬ 
line  a  strategy  for  how  this  would  work. 
We  then  follow  with  a  discussion  of  the 
technological  and  organizational  transi¬ 
tions  likely  to  be  encountered  in  the  course 
of  adopting  this  strategy.  Along  the  way, 
we  describe  an  approach  for  how  to  as¬ 
sess  the  feasibility  of  complex  software 
systems  through  its  incremental  develop¬ 
ment  spiral.  In  addition,  we  describe  a  road 
map  that  lays  out  the  research,  technol- 


TOTAL  KSLOCs  (est);  8447 


OTHER  SHIPBOARD  SYSTEMS 


MISSION  SUPPORT 

Shipwide  Operational 
Readiness  Test  System 
(SORTS) 

157  ■  2% 

Combat  Training  System 
254  -  3% 

Display  System 
223  ■  3% 

H.M.&E 
200  ■  2% 


J  oint  Maritime 
Common  Information 
System  (J  MClS) 
1254  ■  15% 


Unaccounted  Systems 
(20%  Contingency) 
1403  ■  17% 


THEATER  AIR  DOMINANCE 
Cooperative 

Radar  System  Engagement 

310-4%  Capability  (CEO 

1211  •  14% 


COMMAND  & 
CONTROL 


Weapon  Control 
System  (WC  S) 
275  ■  3% 


Advanced  Integrated 
Electronic  Warfare 
System  (AIEWS) 
320  ■  4% 


MARITIME 

DOMINANCE 


U  nderwater  Weapon 
System  (UWS) 
1400  •  16% 


Command  &  Decision 
(C&D)  System 
505 • 6% 


Gun  Weapon 
System  (GWS) 

Advanced  Tomahawk 
Weapons  Control  System 
(ATWCS) 

620-  7%  LAND 

ATTACK 


Figure  3.  Software  Systems  Proposed  for  SC-21  Ships  (SC-21,  1997) 


193 


Acquisition  Review  Quarteriy-  Spring  1998 


ogy,  and  usage  needed  to  support  the  ac¬ 
quisition  of  software  systems,  such  as 
those  for  the  SC-21  line  of  ships. 

The  Virtual  System  Acquisition  Vision 


The  virtual  system  acquisition  (VISTA) 
of  software  systems  refers  to  a  strategic 
process  hy  which  an  evolving  series  of 
ever  more  complete  and  operational  sys¬ 
tem  versions  are  acquired  through  a  se¬ 
ries  of  short  duration  acquisition  life 
cycles.  In  this  way,  emphasis  is  on 
reframing  and  reducing  acquisition  cycle 
times  from  years  to  months  (or  weeks!) 

so  as  to  focus 
attention  on  the 
incremental  and 
iterative  acqui¬ 
sition  of  the 
evolving  capa¬ 
bility  associated 
with  the  target 
software  sys¬ 
tem. 

Reductions 
in  acquisition 
cycle  time  en¬ 
able  an  increase 
in  the  number 
of  incremental  acquisition  cycles  over 
time.  The  VISTA  approach  seeks  to  help 
more  rapidly  identify,  address,  and  resolve 
the  risks  associated  with  the  acquisition 
and  development  of  complex  software-in¬ 
tensive  systems  (Boehm  and  Scacchi, 
1996;  GAO,  1997;  Haimes,  Schooff,  and 
Chittister,  1997).  Thus,  we  need  tools  that 
enable  customers  and  developers  to  rap¬ 
idly  model,  incrementally  evolve,  and  sat¬ 
isfy  (sub)  sets  of  system  capability  require¬ 
ments  in  each  iterative  system  version. 


Early  acquisition  cycles  need  only  to  fo¬ 
cus  on  acquiring  systems  that  represent 
computational  models  and  simulations  of 
the  operational  capability  of  the  target  soft¬ 
ware  system.  Later  acquisition  cycles  then 
focus  on  incrementally  evolving  or  replac¬ 
ing  the  models  and  simulations  with  fully 
operational  system  modules.  In  this  man¬ 
ner,  there  will  always  be  an  operational  ver¬ 
sion  of  the  system  to  evaluate  and  demon¬ 
strate  throughout  the  system’s  acquisition 
and  development  cycle. 

Models  and  simulations  represent  de¬ 
scriptive,  formalized,  and  sharable  under¬ 
standings  of  a  system.  They  can  represent 
a  system’s  concept  of  operation,  architec¬ 
ture,  and  its  ability  to  support  its  intended 
mission.  However,  by  focusing  effort  to 
enable  such  preliminary  system  capabili¬ 
ties  to  move  through  a  fast  acquisition  life 
cycle,  the  goal  is  to  establish  and  validate 
consensus  on  whether  current  models  and 
simulations  of  the  software  system’s  com¬ 
ponents  or  architecture  address  specific 
system  requirements.  In  addition,  the  goal 
is  to  determine  whether  other  underdevel¬ 
oped  or  unrecognized  system  require¬ 
ments  have  emerged  that  must  be  ad¬ 
dressed  in  subsequent  acquisition  and  de¬ 
velopment  cycles.  As  such,  the  goal  here 
is  more  closely  aligned  with  the  idea  of 
incrementally  growing  and  evolving  the 
target  system  in  a  more  organic  and  adap¬ 
tive  manner. 

Our  first  take  on  the  requirements  for 
how  this  might  work  can  be  outlined  as 
follows: 

•  Acquisition  participants  should  be  able 
to  architect,  construct,  assemble,  ex¬ 
ecute,  and  analyze  automated  models 
of  the  overall  software  system  capabil¬ 
ity  for  acquisition. 


"The  virtual  system 
acquisition  (VISTA) 
of  software  systems 
refers  to  a  strategic 
process  by  which  an 
evolving  series  of 
ever  more  complete 
and  operational 
system  versions  are 
acquired  through  a 
series  of  short  dura¬ 
tion  acquisition  life 
cycles." 
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•  Component  models  should  represent 
elements  of  target  environment  (includ¬ 
ing  people),  information  system  infra¬ 
structure,  informational  products,  and 
development,  operation,  and  post-de¬ 
ployment  processes. 

•  The  initial  modeling  and  simulation  of 
these  elements  should  represent  the 
first  pass  through  the  system’s  require¬ 
ments  generation  and  development 
cycle. 

•  Participants  should  he  able  to  itera¬ 
tively  refine  and  incrementally  evolve 
the  system  model  test-hed  from  previ¬ 
ous  steps.  Then  they  should  he  able  to 
selectively  replace  component  models 
with  simulated,  prototype,  or  actual 
component  elements. 

•  Participants  should  be  able  to  itera¬ 
tively  refine  and  evolve  intermediate 
hybrid  system  test-beds  and  progres¬ 
sively  replace  remaining  component 
models  with  simulations,  prototypes,  or 
actual  component  elements.  This  helps 
to  insure  that  a  full-scale  test-bed  is  de¬ 
veloped,  operational,  and  ready  for  post 
research  and  development  deployment 
or  transition  into  commercial  use. 

Subsequently,  we  can  take  this  outline 
of  requirements  for  what  we  envision  and 
reformulate  it  into  a  first-cut  prescriptive 
process,  which  we  call  the  VISTA  Ap¬ 
proach. 

The  VISTA  Approach 


At  this  point,  we  outline  a  series  of 
steps  that  articulate  how  software  system 


acquisition  and  development  become  in¬ 
tertwined  during  virtual  system  acquisi¬ 
tion  processes.  As  modeling  and  simula¬ 
tion  drive  most  of  these  steps,  we  first  de¬ 
scribe  what  types  of  models  are  necessary. 
We  will  also  characterize  what  these  mod¬ 
els  may  look  like,  and  how  they  could  be 
represented.  Then  we  will  briefly  describe 
how  these  models  and  simulations  would 
be  incrementally  replaced  when  evolving 
the  system. 

Modeling  AND  Simulation  in  VISTA 

For  this  discussion,  we  assume  the  en¬ 
visioned  system  is  within  the  scope  of 
available  software  system  product  fami¬ 
lies  at  hand.  If  not,  then  a  domain  analy¬ 
sis  leading  to  the  construction  and  refine¬ 
ment  of  an  appropriate  meta-model  will 
be  needed.  Product  families  and  their  as¬ 
sociated  “smart”  product  models  (SC-21, 
1997),  documents,  development  pro¬ 
cesses,  tools,  and  organizational  agents  are 
defined  and  represented  using  meta-mod- 
els.  Detailed  examples  of  their  use  can  be 
found  elsewhere  (Mi  and  Scacchi,  1990, 
Mi  and  Scacchi,  1996,  Scacchi  and  Mi, 
1997).  We  then  begin  with  the  elicitation 
and  modeling  of  a  virtual  system  model 
(VSM)  for  the  system  to  be  acquired. 

The  VSM  is  a  composite  model — a 
model  composed  from  other  models.  At 
least  three  types  of  models  are  needed  to 
characterize  a  complex  software  system. 
One  class  of  models  is  needed  to  repre¬ 
sent  the  functional  operation  and  data  re¬ 
quired  for  information  processing  by  the 
system.  We  will  call  models  of  this  type 
information  element  models  (lEMs). 
Once  an  IBM  is  replaced  with  an  op¬ 
erational  system  component,  it  becomes 
an  information  element  (IE).  lEMs  are 
used  to  model  the  structure,  behavior. 
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and  performance  (estimated,  measured,  or 
required)  of  the  computing  hardware  and 
software  that  inputs,  processes,  and  out¬ 
puts  system  data.  A  second  class  of  mod¬ 
els  is  needed  to  depict  the  functional  be¬ 
havior  of  the  lEs  embedded  within  a  man- 
machine  system  (e.g.,  command  and  con¬ 
trol  system,  theater  air  dominance  system, 
mission  support  system,  etc.  in  Figure  3) 
to  be  acquired  and  built.  We  call  these 
system  element 
models  (SEMs), 
and  when  re¬ 
placed,  system 
elements  (SEs). 
The  third  class  is 
needed  to  repre¬ 
sent  the  “system 
of  systems,”  sen¬ 
sors,  and  envi¬ 
ronmental  con¬ 
text  in  which  the  embedded  man-machine 
systems  operate.  These  are  called  environ¬ 
ment  element  models  (EEMs),  and  when 
replaced,  environment  elements  (EEs). 

Each  type  of  model  requires  a  compu¬ 
tational  mechanism  that  can  support 
model  entry  and  definition,  interpretation, 
simulation,  and  animated  visualization. 
Commercially  available  discrete-event 
simulation  packages  represent  one  such 
mechanism.  These  packages  are  well 
suited  for  simulating  models  that  are  rep¬ 
resented  as  queuing  networks  whose  ar¬ 
rival  queues  and  service  rates  are  speci¬ 
fied  according  to  statistical  or  algebraic 
models. 

Different  types  of  models  may  require 
different  kinds  of  simulation;  thus  differ¬ 
ent  tools  may  be  needed.  For  example, 
modeling  and  simulating  the  “look  and 
feel”  and  event-based  operation  of  a 
graphic  user  interface  for  a  Military 


Support  Training  System  may  employ 
multimedia  authoring  or  navigation  tools. 
Commercially  available  tools  such  as 
Macromedia  Director,  Microsoft 
PowerPoint,  or  even  Web  browsers  access¬ 
ing  virtual  reality  content  across  an 
intranet  can  be  used  for  this  purpose. 
Rapid  application  development  (RAD) 
tools  (Visual  Basic,  PowerBuilder,  Visual 
Cafe  for  Java,  etc.)  and  expert  system 
shells  (e.g.,  M.4  from  Teknowledge)  that 
support  software  prototyping  or  visual 
programming  with  persistent  databases 
can  enable  the  modeling  and  simulation 
of  complex,  rule-based,  state-transition 
software  applications.  These  are  tools  for 
developing  virtual  prototypes  of  lEs 
(Garcia,  Gocke,  and  Johnson,  1994).  With 
these  tools,  it  is  possible  to  model,  simu¬ 
late,  or  approximate  the  behavior  of  soft¬ 
ware  applications  using  stubbed,  canned, 
or  pre-calculated  input  and  output  data 
values  as  place  holders  for  complex  cal¬ 
culations  required  of  an  eventual  software 
system  implementation.  As  such,  model¬ 
ing  and  simulating  a  VSM  may  benefit 
from  use  of  a  computing  environment 
where  multiple  types  of  models  and  simu¬ 
lations  can  be  defined,  composed,  simu¬ 
lated,  and  displayed.  Furthermore,  it  may 
be  desirable  for  such  an  environment  to 
be  accessible  over  the  Internet  to  facili¬ 
tate  the  sharing,  discussion,  and  review  of 
modeling  and  simulation  efforts  among 
the  different  organizational  representatives 
participating  in  a  program  acquisition. 

lEMs  can  be  modeled  in  a  variety  of 
ways.  A  common  tactic  may  be  to  depict 
lEMs  as  hierarchically  decomposed  black 
boxes  (closed  systems),  white  boxes  (open 
systems),  or  gray  boxes  (closed  systems 
with  limited  internal  visibility).  These 
boxes  are  placeholders  for  hardware  or 


"  Each  type  of  model 
requires  a  computa¬ 
tional  mechanism 
that  can  support 
model  entry  and 
definition,  interpre¬ 
tation,  simulation, 
and  animated 
visualization." 
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software  system  modules  that  are  to  be 
acquired  and  developed.  Each  box  can 
represent  a  computation  unit  that  can  re¬ 
ceive  inputs  or  event  signals,  perform 
some  calculation,  then  produce  some  out¬ 
puts,  state  transition,  or  some  new  event. 
They  can  be  modeled  and  simulated  us¬ 
ing  any  of  the  tools  noted  above.  How¬ 
ever,  depending  on  the  kind  of  acquisition 
concern  we  wish  to  address,  particular  tool 
choices  may  be  most  appropriate.  For  ex¬ 
ample,  in  SC-21-class  ships,  it  may  ini¬ 
tially  be  an  open  question  as  to  what  level 
of  computer  performance  is  required  to 
satisfactorily  operate  mission  support  soft¬ 
ware  systems.  A  desktop  personal  com¬ 
puter  is  probably  inadequate,  while  a  large 
mainframe  may  be  too  much,  too  large, 
or  too  expensive.  Thus,  it  seems  appro¬ 
priate  to  consider  modeling  the  required 
computing  hardware  as  a  computational 
module  with  mid-range  performance  or 
processing  throughput  (i.e.,  10-100  trans¬ 
actions  per  second)  as  a  starting  point. 
Further,  since  determining  system  perfor¬ 
mance  throughput  under  different  mission 
support  workloads  or  traffic  volume  is 
necessary,  then  a  discrete-event  simulation 
package  may  be  best  to  use. 

However,  the  software  system  modules 
required  to  operate  on  this  anticipated 
hardware  may  or  may  not  be  so  readily 
understood.  If  we  initially  have  little 
knowledge  of  what  calculations  or  infor¬ 
mation  is  required  in  processing  mission 
support  data,  then  the  software’s  model 
may  simply  equate  to  that  of  a  module  that 
produces  a  stream  of  input  and  output  data 
transactions,  say  in  the  range  of  0-8  trans¬ 
actions  per  second.  Alternatively,  as 
knowledge  increases,  software  modules 
may  be  identified  that  perform  different 
functions. 


It  should  be  possible  to  evaluate  alter¬ 
native  architectural  configurations  or  com¬ 
positions  of  software  modules  as  a  way  to 
understand  whether  system  performance 
parameters  are  sensitive  to  the  alternatives. 

For  example,  in  a  mission  support  com¬ 
bat  training  sys¬ 
tem,  one  could 
separate  user  in¬ 
put  capture  and 
verification, 
calculation  and 
database  up¬ 
date,  and  output 
to  user  display 
as  three  distinct 
software  mod¬ 
ules.  Should 
these  modules 
be  configured  in  as  a  linear  sequence,  a 
fully  interconnected  concurrent  network, 
or  bundled  together  as  a  single  large  mod¬ 
ule?  Which  alternative  configuration 
would  be  easiest  to  build  and  test?  Which 
would  have  the  best  performance?  Which 
would  cost  the  least?  Perhaps  we  could 
guess  the  answer(s).  However,  if  we  can 
model,  simulate,  and  collaboratively  dis¬ 
cuss  the  three  architectural  alternatives, 
then  we  can  begin  to  articulate  a  basis  that 
leads  to  a  consensus  answer  that  can  be 
backed  up  with  evaluated  alternatives  and 
simulation  results. 

Would  the  consensus  results  from  such 
a  modeling  and  simulation  exercise  be 
more  believable  than  someone’s  best 
guess?  In  lieu  of  some  controlled  experi¬ 
ment,  the  answer  to  that  is  subjective. 
However,  the  modeling  and  simulation  re¬ 
sults  would  be  explicit,  repeatable,  and 
subject  to  tradeoff  analysis  and  consen¬ 
sus  validation.  In  addition,  these  results 
can  be  open  to  challenge  and  reformation 


"It  should  be 
possible  to  evaluate 
alternative  architec¬ 
tural  configurations 
or  compositions  of 
software  modules  as 
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in  a  manner  that  may  be  more  tractable 
than  someone’s  best  guess.  Nonetheless, 
if  someone  such  as  a  software  architect 
experienced  in  the  design  of  mission  sup¬ 
port  combat  training  systems  can  argue 
persuasively  about  his  or  her  best  guess, 
then  this  alternative  could  be  represented 
in  an  lEM,  simulated,  compared  and  vali¬ 
dated. 

SEMs  provide  the  ability  to  embed  soft¬ 
ware  systems  within  man-machine  sys¬ 
tems  settings.  SEMs  embed  lEMs  or  lEs 
in  a  user-driven  input  and  output  environ¬ 
ment.  Users  create  inputs  in  response  to 
their  work  assignments,  and  to  informa¬ 
tion  output  from  the  system  and  displayed 
to  them.  Eor  example,  when  using  a  train¬ 
ing  system,  users  may  select  among 

“menu  items” 
or  enter  system 
commands. 
This  may  cause 
the  training  sys¬ 
tem  to  process 
their  input,  pro¬ 
vide  an  updated 
user  interface 
display,  then  wait  for  the  user’s  next  input 
action.  As  such,  SEMs  must  model  user 
behavior  in  driving  and  responding  to  sys¬ 
tem  actions  or  events,  as  well  as  model 
system  behavior  in  response  to  user  ac¬ 
tions. 

While  user  behavior  is  open-ended, 
only  a  range  of  possible  user- system  in¬ 
teractions  will  be  modeled.  Eor  example, 
users  can  only  provide  either  acceptable 
input,  acceptable  but  erroneous  input  that 
is  detected,  or  unacceptable  input.  SEM 
simulation  may  include  the  use  of  software 
“drivers”  that  cause  the  arrival  of  user  in¬ 
put  or  input  events,  together  with  system 
responses  or  service  time  intervals  that 


follow  statistical  formulas  or  some  other 
characterization  function.  SEM  simulation 
can  then  be  supported  using  common  dis¬ 
crete-event  simulation  tools  if  user  behav¬ 
ior  is  being  simulated.  Alternatively,  if  the 
system’s  behavior  is  being  simulated  for 
real  users,  then  multimedia  or  RAD  tools 
may  be  used  to  provide  simulated  user 
interfaces  for  real  users  to  evaluate.  As 
with  the  lEM  simulations,  the  plausibility 
and  consensus  validation  process  noted 
above  will  also  apply  here. 

EEMs  provide  the  ability  to  embed  the 
man-machine  system  in  its  overall  envi¬ 
ronmental  context.  Eor  example,  weapons 
control  systems  may  be  designed  to  use 
various  sensors  (radar,  sonar,  satellites, 
etc.)  to  zero  in  on  their  targets.  These  sen¬ 
sors  may  themselves  be  complex  systems. 
Similarly,  weapons  control  systems  will 
interact  with  many  other  shipboard  sys¬ 
tems,  including  those  for  mission  support, 
and  command  and  control.  These  systems 
must  act  in  concert  to  realize  the  overall 
effectiveness  of  a  complex  system  of  sys¬ 
tems  that  a  ship  of  the  SC-21  class  repre¬ 
sents.  Therefore,  EEMs  must  model  the 
interoperation  and  integration  of  multiple 
systems.  This  may  entail  modeling  the 
overall  patterns  of  data  or  messaging  traf¬ 
fic  between  systems,  as  well  as  between 
systems  and  users  as  a  group. 

Alternatively,  in  response  to  different 
scenarios  for  total  system  engagement,  the 
EEMs  may  be  used  to  model  the  ebb  and 
flow  of  information  across  the  system  of 
systems.  With  this,  we  expect  that  the  pat¬ 
terns  of  information  flow  on  a  SC-21  ship 
in  response  to  a  hostile  attack  scenario  will 
be  different  than  the  flows  associated  with 
routine  ship  operations  and  maintenance 
scenario.  Subsequently,  these  information 
traffic  or  flow  patterns  can  be  modeled 


"  ...users  can  only 
provide  either 
acceptable  input, 
acceptable  but 
erroneous  input  that 
is  detected,  or 
unacceptable  input." 
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and  simulated  using  discrete-event 
simulation  capabilities,  and  the  valida¬ 
tion  process  described  earlier  again  ap¬ 
plies  here. 

Overall,  the  remaining  challenge  is  to 
integrate  and  interoperate  the  different 
models,  simulations,  and  elements.  This 
is  the  purpose  of  a  collaborative  test-bed 
such  as  a  Battleship  Lab  for  SC-21  class 
ships  (Cothran,  1996;  Kouzes,  Meyers, 
and  Wulf,  1996;  Wilson,  1996).  It  may 
serve  to  support  the  integration  and 
interopera-tion  of  multiple,  mixed  mode 
models  and  simulation  tools,  as  well  as  of 
multiple  system  elements  with  many  mod¬ 
els  and  simulations.  At  this  time,  devel¬ 
oping  such  a  test-bed  may  be  an  expen¬ 
sive  but  nonetheless  necessary  proposi¬ 
tion.  However,  even  if  the  cost  of  such  test¬ 
beds  approaches  5-10  percent  of  system 
development  costs,  such  an  investment 
may  be  reasonable  given  that  the  total 
overall  effectiveness  of  the  system  plat¬ 
form  is  long-lived,  software-intensive,  and 
thus  software-dependent. 

Again,  our  objective  is  to  find  ways  to 
facilitate  the  articulation  and  elaboration 
of  requirements,  risks,  and  cost-drivers  for 
complex,  software-intensive  systems.  It 
also  assists  those  involved  in  system  ac¬ 
quisition  to  understand  how  modeling  and 
simulation  tools  and  techniques  can  be 
used.  As  such,  we  now  provide  a  brief  de¬ 
scription  of  how  incremental  system  ac¬ 
quisition  and  development  would  replace 
the  system  models  with  operational  ele¬ 
ments  and  system  components. 

Incremental  Replacement  of  System 
Models  WITH  Operational  System 
Components 

Given  that  we  have  outlined  the  over¬ 
all  VISTA  approach  for  modeling  and 


simulation,  we  can  describe  how  this  ap¬ 
proach  could  work  in  the  context  of  ac¬ 
quiring  a  software  system.  We  examine 
software  sys¬ 
tems  for  SC-21 
class  ships,  al¬ 
though  we  limit 
our  discussion 
to  a  representa¬ 
tive  subset  of 
software  sys¬ 
tems  for  these 
ships.  We  use 
mission  support 
systems  in  our  discussion.  Accordingly, 
we  describe  how  the  information,  system, 
and  environment  elements  for  mission 
support  are  incrementally  acquired  and  de¬ 
veloped  in  a  series  of  spiraling  iterations 
following  the  approach.  We  show  how 
these  elements  can  change  while  progress¬ 
ing  from  models  to  actual  software  sys¬ 
tem  architectures.  Similarly,  we  identify 
what  difference  it  makes  to  improve  the 
acquisition  of  software. 

The  VISTA  approach  begins  with  the 
acquisition  of  a  virtual  system  model  for 
mission  support.  A  team  of  participants 
from  the  program  office,  acquisition  di¬ 
rectorate,  user  representatives,  and  pro¬ 
spective  contractors  may  specify  the 
VSM.  The  team  might  employ  a  wide-area 
collaboratory  environment  to  share  and 
record  information  giving  rise  to  the  VSM. 
However,  perhaps  only  the  contractors 
would  be  tasked  with  the  modeling  devel¬ 
opment  activity. 

The  VSM  can  be  subjected  to  analysis, 
simulation,  redesign,  visualization,  and 
walk-through.  Figure  4  provides  a  con¬ 
cept  diagram  for  how  this  might  appear 
if  we  focus  on  an  architectural  configu¬ 
ration  of  lEMs  (the  computer  or  software 
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softwa  re  -  i  ntensi  ve 
systems." 


199 


Acquisition  Review  Quarteriy-  Spring  1998 


elements),  SEMs  (the  physical  or  human 
elements),  and  the  EEMs  (the  external 
stimuli  outside  the  system  boundary).  As 
shown  in  Eigures  4  through  6,  multiple 
lEMs,  SEMs,  and  EEMs  are  used.  This 
reflects  the  notion  that  the  scope  and  depth 
of  different  models  may  he  limited, 
compartmentalized,  or  may  he  divided 
among  different  organization  contrac¬ 
tors,  suh-contractors,  program  office, 
etc.). 

In  acquiring  an  initial  VSM  for  mission 
support  systems,  many  kinds  of  models 


are  used.  Eor  example,  lEMs  designate 
computer  hardware  and  software  sub¬ 
systems.  SEMs  denote  operational  readi¬ 
ness  test  system,  combat  training  system, 
and  display  system.  Also,  EEMs  are 
needed  for  other  shipboard  systems  (e.g., 
command  and  control  system),  sensors, 
and  environment  factors  (weather,  com¬ 
bat  versus  routine  operations,  etc.).  Em¬ 
phasis  in  developing  the  initial  VSM  is  on 
deciding  what  kinds  of  modeling  and 
simulation  tools  to  use  for  the  different 
types  of  model  elements.  Also,  emphasis 


Figure  4.  Initial  VSM  Development  Cycle 
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is  directed  at  how  to  integrate  the  mod¬ 
eled  elements  into  an  architectural  con¬ 
figuration  so  that  the  simulated  elements 
can  interoperate.  This  is  shown  in  Figure 
4.  Subsequently,  if  all  VSM  element  mod¬ 
els  can  he  satisfactorily  simulated  at  this 
point  using  a  discrete-event  simulation 
package,  then  the  integration  and 
interoperation  challenges  are  reduced  or 
eliminated. 

Given  that  the  VSM  can  he  developed, 
we  need  to  exercise  and  test  it  to  explore 
the  proposed  system’s  ability  to  satisfy  the 
requirements  of  its  customers,  users,  de¬ 
velopment  contractors,  program  manag¬ 
ers,  and  others.  Similarly,  we  need  to  ex¬ 
plore  the  tradeoff  among  desired  system 
functional  capabilities,  performance  ob¬ 
jectives,  and  costs.  A  wide-area  software 
requirement  negotiation  and  collaboration 
environment,  such  as  the  Win-Win  envi¬ 
ronment  developed  at  USC  (Boehm  et  ah, 
1995),  could  be  used  for  this  purpose. 

Collaboration  environments,  like  Win- 
Win,  enable  various  system  acquisition 
and  development  participants  to  discuss 
the  relative  merits  of  the  VSM,  its  ability 
to  identify  or  demonstrate  system  require¬ 
ments,  and  to  determine  and  validate 
where  there  is  consensus  in  these  areas. 
For  example,  user  representatives  may  be¬ 
lieve  that  response  time  to  user  input  com¬ 
mands  should  not  be  more  than  one  sec¬ 
ond.  The  contractors  may  note  that  while 
such  system  performance  may  be  essen¬ 
tial  for  the  combat  training  system,  it  may 
not  be  needed  by  the  operational  readiness 
test  system.  Thus,  it  would  be  unneces¬ 
sarily  costly  to  the  program  to  make  it  so. 

To  help  clarify  their  position,  the  con¬ 
tractors  input  the  two  alternative  sys¬ 
tem  performance  requirements  into 
the  computer  hardware  IBM  simulation. 


Executing  the  simulation  using  the  two 
performance  measures  may  produce  inter¬ 
esting  comparative  results.  For  instance, 
if  users  of  the  operational  readiness  test 
system  can  accept  a  four-second  response 
time,  the  required  computer  hardware  per¬ 
formance  can  be  realized  at  an  apprecia¬ 
bly  lower  cost,  perhaps  saving  millions  of 
dollars  (Boehm  and  Scacchi,  1996).  With 
this  result  at  hand,  the  team  agrees  to  re¬ 
vise  the  require¬ 
ments  for  this  "...we  need  to 
information ele-  explore  the  tradeoff 
ment.  As  such,  among  desired 
the  VSM  is  re-  system  functional 
vised  and  cali-  capabilities,  perfor- 
brated  to  use  ma nee  objectives, 
this  informa-  costs." 

tion.  This  helps 

to  illustrate  the  how  iterative  analysis, 
simulation,  performance  monitoring,  and 
benchmarking  can  improve  understanding 
system  requirements,  and  how  to  identify 
areas  where  virtual  system  acquisition  ef¬ 
forts  can  reduce  costs. 

In  a  later  acquisition  and  development 
cycle,  the  team  decides  to  assemble  par¬ 
ticular  element  components  using  fully 
operational  and  architecturally  configured 
subassemblies.  Flere,  the  contractors  must 
replace  the  corresponding  model  or  simu¬ 
lation  elements  with  operational  proto¬ 
types  or  actual  operating  elements.  Fig¬ 
ure  5  provides  a  diagram  for  how  this  hy¬ 
brid  system  and  hybrid  test-bed  might 
appear.  For  example,  an  EEM  for  sonar 
and  radar  sensors  may  be  replaced  with  a 
test-bed  instrument  that  can  generate  re¬ 
alistic  sensor  input  data.  The  display  sys¬ 
tem  for  mission  support  may  now  be  fully 
operational,  and  the  computer  hardware 
that  supports  the  display  system  may  be 
operational.  Accordingly,  the  display 


201 


Acquisition  Review  Quarteriy-  Spring  1998 


system  SEM  can  be  replaced  with  the  op¬ 
erational  display  system  SE,  and  the  com¬ 
puter  hardware  lEM  can  be  replace  with 
its  corresponding  IE.  Nonetheless,  even 
with  these  virtual  system  elements  re¬ 
placed  with  operational  components,  the 
overall  VSM  test-bed  can  still  be  accessed 
and  evaluated  using  a  collaborative  wide- 
area  environment  for  requirements  nego¬ 
tiation  and  validation  (Boehm  et  al,  1995, 
Kouzes,  Meyers,  and  Wulf,  1996). 

Once  operational  components  are  inte¬ 
grated  into  the  V SM,  it  becomes  possible 


to  more  systematically  walk  through,  ex¬ 
ercise,  monitor,  record,  and  replay  the  re¬ 
vised  VSM  hybrid  tested.  This  can  help 
to  validate  choices,  explore  further 
tradeoffs,  and  articulate  systemic  bottle¬ 
necks  or  processing  failures  in  the 
system’s  architecture  (Scacchi  and  Mi, 
1997).  Eor  example,  while  evaluating  the 
operational  performance  of  the  display 
system  that  interacts  with  the  combat  train¬ 
ing  system,  it  appears  to  users  that  im¬ 
portant  information  of  the  user  display 
is  being  updated  too  fast  for  users  to  act 


Figure  5.  Intermediate  VSM  Development  Cycle 
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appropriately.  Instead,  the  rate  of  informa¬ 
tion  display  needs  to  be  slowed,  or  the  in¬ 
formation  content  needs  to  be  aggregated 
and  summarized.  Thus,  from  the  user 
standpoint,  the  current  system  operation 
in  the  VSM  is  risky  or  not  feasible.  As 
before,  system  element  parameters  need 
to  be  adjusted,  otherwise  alternative  sys¬ 
tem  architectures  need  to  be  considered 
and  evaluated. 

With  an  intermediate  VSM,  further 
elaboration  is  needed  to  field  a  deployable 
system  (see  Figure  2).  If  this  is  the  case, 
then  the  acquisition  and  development  team 
must  revisit  the  selection  of  software  and 
system  components  to  develop.  Other¬ 
wise,  they  can  perform  partly  simulated 
operational  test  and  evaluation,  then  ex¬ 
perimentally  field  the  system  either  across 
a  wide-area  intranet  test-bed  (Scacchi  and 
Noll,  1997),  or  in  a  battleship  lab  test-bed, 
in  order  to  continue  to  calibrate  and  re¬ 
fine  the  VSM  for  further  post  deployment 
studies.  Thus,  here  we  seek  to  illustrate 
how  virtual  system  acquisition  can  help 
identify  potential  risks  and  attendant  cost 
drivers  that  may  not  be  manifest  until  field 
operation  stages  of  the  system’s  overall 
life  cycle. 

When  further  system  capabilities  are 
needed,  the  participants  can  exercise  the 
VSM.  This  means  they  may  adjust  simu¬ 
lation  parameters,  have  users  test-drive 
and  evaluate  system  prototypes,  etc.,  to  de¬ 
termine  tradeoffs  and  validate  priorities 
through  consensus.  Consequently,  they 
may  choose  to  revisit  the  selection  of  com¬ 
ponents  to  acquire  and  develop.  Jumping 
ahead,  the  acquisition  and  development 
participants  can  continue  to  evolve  and 
continuously  improve  the  emerging  sys¬ 
tem  architecture.  This  requires  a  revisit 
through  the  preceding  steps  until  all 


remaining  system  component  simulations 
or  prototypes  are  replaced  by  their  opera¬ 
tional  counterparts.  Figure  6  provides  a 
diagram  for  how  this  late  stage  system 
architecture  might  now  appear. 

Here  we  see  that  all  of  the  system  and 
information  element  models  have  been 
replaced  with  their  operational  elements. 
Some  EEMs  remain,  however,  since  they 
may  designate  other  major  shipboard  sys¬ 
tem  undergoing  concurrent  development. 
Thus,  while  the  sensor  test-bed  may  be  op¬ 
erational  and  integrated  to  interoperate 
with  the  mission  support  systems,  the 
command  and  control  system  as  well  as 
other  major  sys¬ 
tems  may  not 
yet  be  opera¬ 
tional  and  avail¬ 
able  for  integra¬ 
tion.  But  these 
other  systems 
must  still  con¬ 
form  to  their 
EEMs  place¬ 
holders  for  use 
with  the  mis¬ 
sion  support  system.  Subsequently,  an  ad¬ 
ditional  capability  is  required  for  charac¬ 
terizing  or  extracting  an  updated  EEM 
from  this  VSM.  This  updated  information 
needs  to  be  used  in  other  VSMs  corre¬ 
sponding  to  environment  elements  that 
constitute  the  system  of  systems.  Erom  a 
technical  standpoint,  this  requires  address¬ 
ing  problems  in  system  component  inter¬ 
face  definition,  and  in  managing  concur¬ 
rent  access  to  different  versions  of  these 
components  or  model  placeholders.  Erom 
an  organizational  standpoint,  failing  to 
coordinate  access  and  propagation  of  com¬ 
ponent  interface  definitions  or  changes  is 
a  common  problem  that  precipitates 
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difficulty  in  systems  integration  and 
interoperability  Knowing  where  problems 
lie,  and  being  able  to  prevent  or  circum¬ 
vent  them  through  virtual  system  acquisi¬ 
tion,  provides  another  capability  for  reduc¬ 
ing  risks  and  costs  associated  with  the  de¬ 
velopment  of  software-intensive  systems. 

Finally,  throughout  the  overall  VISTA 
process  we  have  just  outlined,  current  best 
practices  in  software  program  manage¬ 
ment  (SPMN,  1997)  and  a  consensus  rec¬ 
ommendation  from  the  Blue  Ribbon  Pan¬ 
els  (Boehm  and  Scacchi,  1996)  point  to 


the  opportunity  to  track  and  manage  soft¬ 
ware  feasibility  and  risk  using  new  pro¬ 
gram  management  support  tools.  Figure 
7  provides  a  view  of  the  user  interface 
“dashboard”  to  such  a  tool,  as  well  as  sug¬ 
gesting  how  program  management  infor¬ 
mation  may  be  conveyed. 

Participants  in  a  virtual  system  acqui¬ 
sition  also  need  to  track,  organize,  record, 
and  store  records  of  the  steps  they  took. 
Furthermore,  they  may  need  to  document 
what  transpired,  how,  by  whom,  why,  and 
with  what  outcomes.  These  records  and 
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documents  represent  important  knowledge 
assets  emerging  from  the  acquisition  ef¬ 
fort.  Capturing  and  organizing  this  infor¬ 
mation  is  often  cumhersome  and  haphaz¬ 
ard.  However,  we  find  that  these  knowl¬ 
edge  assets  can  he  easily  captured  and 
linked  to  the  virtual  system  models  and 
elements  using  hypertext  mechanisms 
commonly  available  in  information  shar¬ 
ing  and  requirement  negotiation  support 
environments  (Noll  and  Scacchi,  1991, 
Boehm,  et  al.,  1995),  rather  than  being  cast 
as  a  mountain  of  paper. 

With  this  basis  for  VISTA  approach,  we 
can  now  put  forward  a  matrix  of  the  tran¬ 
sitional  steps  for  how  to  realize  the  tech¬ 
nical  basis  for  supporting  VISTA.  This  is 
then  followed  by  a  description  of  the  or¬ 
ganizational  transitions  for  VISTA. 


Mapping  THE  Technological 
Transitions  TO  VISTA 


Although  the  VISTA-based  approach 
may  be  a  radical  departure  from  traditional 
system  acquisition  practice,  getting  there 
may  be  best  achieved  in  an  evolutionary 
manner.  To  be  clear,  the  VISTA  approach 
is  new,  but  the  tools,  techniques,  and  con¬ 
cepts  it  involves — incremental  acquisition 
and  development,  virtual  prototyping, 
wide-area  collaboratories,  software  re¬ 
quirements  negotiation  and  validation  en¬ 
vironments,  etc. — are  beginning  to  be  used 
in  system  acquisition  efforts.  Thus,  as 
VISTA  implies  the  need  to  use  an  auto¬ 
mated  support  environment  for  modeling, 
simulation,  and  program  management,  the 


Figure  7.  A  Program  Management  Dashboard  for 
Assessing  Software  Development  Progress 
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required  tools  and  techniques  for  such  an 
environment  can  he  investigated,  refined, 
and  deployed  in  a  multistaged  manner.  An 
integrated  information  management  envi¬ 
ronment  to  support  the  acquisition  and  de¬ 
velopment  of  complex  software  systems, 
such  as  those  for  the  SC-21  program,  is 
not  yet  available.  However,  such  an  envi¬ 
ronment  can  he  constructed  and  put  into 
use  following  the  road  map  outlined  be¬ 
low  and  elsewhere  (Boehm  and  Scacchi, 
1996).  The  resulting  environment  can  then 
be  positioned  to  support  large  system  ac¬ 
quisition  programs. 

We  can  explain  the  technological  basis 
to  support  the  transition  to  VISTA  in  terms 
that  cover  its  anticipated  use  in  acquisi¬ 
tion,  (its  technology,  and  the  research 
needed  to  realize  its  technology  and  us¬ 
age.  At  the  same  time,  we  can  character¬ 
ize  how  each  of  these  three  aspects  corre¬ 
spond  to  the 
software  system 
development 
life  cycle  stages 
that  include  sys¬ 
tem  concept 
definition,  ar¬ 
chitecture  defi¬ 
nition,  and  on¬ 
going  spiral  de¬ 
velopment.  Together,  we  can  associate 
each  of  these  into  a  matrix  that  organizes 
the  VISTA  research,  technology,  and  ac¬ 
quisition  usage  as  shown  in  Table  1 . 

Moving  from  top  to  bottom,  right  to  left, 
we  can  outline  the  associated  operational 
concepts  for  VISTA,  thereby  characteriz¬ 
ing  the  technological  transitions  “from 
ends  to  means.” 

•  Concept  feasibility  determination: 

Given  a  new  mission  or  strategic 


objective,  determine  whether  appropri¬ 
ate  technology,  architectures,  and  re¬ 
sources  can  be  feasibly  brought  to¬ 
gether  into  a  new  software-intensive 
system  in  an  affordable  and  timely 
manner. 

Architecture  feasibility  determination: 
Given  a  proposed  software  system  ar¬ 
chitecture,  determine  whether  it  can 
satisfy  mission  or  strategic  objectives 
in  an  affordable  and  timely  manner. 

Virtual  system  acquisition:  Given  a  fea¬ 
sible  system  concept  and  architecture, 
acquire  the  proposed  architecture  as  a 
series  of  modeled,  simulated,  or  imple¬ 
mented  subsystems.  These  subsystems 
can  be  developed  by  progressively  re¬ 
placing  or  transforming  the  modeled  or 
simulated  subsystems  with  prototyped 
or  real  implementations. 

VISTA- 1,  top-level  feasibility  advisor, 
parametric  models:  A  top-level  feasi¬ 
bility  analysis-modeling  environment 
is  needed  for  checking  established  ac¬ 
quisition  heuristics  and  parameters. 
Such  an  environment  could  be  used  to 
determine  whether  the  candidate  tech¬ 
nologies,  architectures,  and  resources 
can  be  brought  together  to  address  a 
new  mission  or  strategic  objectives. 
This  environment  would  represent  the 
first  version  of  the  VISTA  support  en¬ 
vironment  (VISTA- 1).  The  environ¬ 
ment  proposed  by  the  software  pro¬ 
gram  managers  network  (Figure  7), 
together  with  software  cost  estima¬ 
tion  tools,  software  requirements  ne¬ 
gotiation  capabilities,  and  access  to 
a  collection  of  software  feasibility 
heuristics  are  available  today  for 


"To  be  dear,  the 
VISTA  approach  is 
new,  but  the  tools, 
techniques,  and 
concepts  it  involves, 
are  beginning  to  be 
used  in  system 
acquisition  efforts." 
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Table  1.  VISTA  Research,  Technology,  and  Usage  Context 
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0 

SDEs 

environment 

acquisition 

(/) 

experimentation  and  initial  usage 
(Boehm  et  aL,  1995;  STSC,  1995; 
SPMN,  1997). 

•  VISTA-2,  software-intensive  models 
and  simulations:  VISTA-2  is  an  en¬ 
hanced  VISTA- 1  environment  for  soft- 
ware-intensive  modeling  and  simula¬ 
tion.  It  could  he  used  to  prototype,  ana¬ 
lyze,  and  execute  system  architectural 
capahilities  and  functionality,  then  rec¬ 
oncile  these  performance  characteris¬ 
tics  against  the  cost,  schedule,  and 
quality  tradeoff  among  proposed  archi¬ 
tectural  design  alternatives.  VISTA-2 
is  used  order  to  determine  whether  pro¬ 
posed  application  system  architectures 
are  viable. 


•  VISTA-3,  hybrid  measurement,  mod¬ 
eling  and  simulation  environment:  The 
VISTA-3  environment  is  built  to  ex¬ 
pand  the  capabilities  of  VISTA-2.  In 
order  to  acquire  incrementally  devel¬ 
oped  software  application  systems, 
VISTA-3  can  be  used  to  support  the 
cooperative  modeling,  simulation,  and 
measurement  of  the  performance  ca¬ 
pabilities  of  an  evolving  application 
system,  its  subsystems,  and  their  col¬ 
lective  architectural  design. 

•  Software  feasibility  heuristics:  We 
need  to  collect,  validate,  and  refine  a 
knowledge  base  of  “best  practice”  heu¬ 
ristics  for  software  system  acquisition, 
architecture,  and  overall  development. 
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This  knowledge  could  provide  plau¬ 
sible  advice  for  how  to  assess  the  top- 
level  feasibility  of  an  emerging  soft¬ 
ware  application  system.  These  heuris¬ 
tics  can  help  determine  what  matters, 
and  which  technology,  architecture,  or 
resource  characteristics  affect  the  over¬ 
all  feasibility  of  the  system  (Rechtin, 
1991;  STSC,  1995;  SPMN,  1997). 


available  software  engineering  envi¬ 
ronments. 

With  this  context  for  VISTA  research, 
technology,  and  acquisition  usage  in  mind, 
we  can  now  more  simply  characterize  the 
overall  concept  for  how  VISTA  might  be 
employed.  This  can  be  outlined  in  four 
steps: 


•  Architecture  representation  and  analy¬ 
sis  modeling  and  simulation  (M&S), 
and  advanced  cost,  schedule,  and  qual¬ 
ity  M&S:  We  need  to  research  and  de¬ 
velop  new  architectural  representations 
that  support  incremental  building  and 

evolving  large 
application 
systems  using 
models  or  simu¬ 
lations.  These 
representations 
also  must  be 
able  to  incorpo¬ 
rate  the  archi¬ 
tectures  of  its 
subsystems, 
whether  as  already  implemented  or 
newly  developed  components.  We  fur¬ 
ther  need  to  be  able  to  represent  the 
cost,  schedule,  and  quality  associated 
with  the  development  of  different  soft¬ 
ware  components  or  architectural  con¬ 
figurations. 

•  Integration  into  commercial  software 
development  environments  (SDEs): 
In  order  for  VISTA  tools  to  be 
broadly  applied  across  the  spectrum 
of  DoD  or  other  large-scale  system 
acquisitions,  they  need  to  become  avail¬ 
able  as  extensions  (e.g.,  “plug-ins”  or 
“helper  applications”)  to  commercially 


Pre-proposal  requirements  analysis: 
Use  the  VISTA  environment  to  analyze 
feasibility  of  the  system’s  concept  and 
mission  requirements  (a  sanity  check 
on  the  technical  perspective  for  a  new 
mission  program  to  determine  rough 
order  of  magnitude  for  cost,  architec¬ 
ture,  other  risk  items,  etc.)  prior  to  the 
Request  For  Proposal. 

Proposal  analysis:  Upon  receipt  of  de¬ 
velopment  contractors’  proposals,  use 
VISTA  to  analyze  each  proposal  for 
feasibility,  determine  which  proposals 
are  in  competitive  range,  and  what  as¬ 
sistance  is  needed  to  evaluate  the  tech¬ 
nical  perspective  (e.g.,  architecture)  of 
those  proposals  within  competitive 
range. 

Project  startup:  Use  VISTA  to  evalu¬ 
ate  the  feasibility  of  resources  (cost, 
people,  etc.)  and  schedule  of  proposed 
system  design.  This  could  also  be  used 
for  “fly-off’  scenarios  as  well,  when 
competing  designs  are  being  evaluated. 

Ongoing  program  review:  Use  VISTA 
to  re-analyze  feasibility  at  progress 
milestones  during  development  life 
cycle,  as  well  as  when  significant  pro¬ 
gram  or  system  requirements  changes 
occur. 


"  We  need  to  collect, 
validate,  and  refine 
a  knowledge  base 
of  best  practice 
heuristics  for  soft¬ 
ware  system  acquisi 
tion,  architecture, 
and  overall 
development." 
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VISTA  should  be  applicable  to  prod¬ 
uct-line  software  system  architectures,  as 
well  as  to  unique  non-product-line  soft¬ 
ware  systems.  It  appears  that  the  VISTA 
may  be  more  readily  suited  to  product-line 
software  system  architectures,  since  their 
recurring  development  can  accommodate 
the  collection,  refinement,  and  calibration 
of  the  VISTA  for  the  product  line’s  appli¬ 
cation  domain.  However,  it  may  also  be 
useful  for  (portions  of)  non-product-line 
software,  especially  where  a  well-con¬ 
ceived  reference  model  standard,  such  as 
the  Air  Force’s  Horizon  Architecture,  de¬ 
fines  the  software.  Nonetheless,  within  the 
domains  of  C4I,  air  traffic  control,  man¬ 
agement  information  systems,  and  other 
applications,  we  may  expect  future  sys¬ 
tems  to  be  more  likely  to  conform  to  prod¬ 
uct-line  architectures.  Industry  trends  and 
corporate  strategies  may  then  lead  system 
development  contractors  to  focus  their 
expertise  and  core  competencies  around 
the  mastery  of  product  lines,  rather  than 
individual  products  or  contracts. 

Managing  the  Organizational 
Transitions  TO  VISTA 


The  move  to  adopt,  implement,  make 
routine,  and  replicate  the  VISTA  approach 
seems  to  be  a  radical  departure  from  cur¬ 
rent  system  acquisition  practices  and  pro¬ 
cesses.  While  we  believe  that  a  compel¬ 
ling  technical  argument  can  be  made  for 
the  VISTA  approach,  we  must  also  address 
the  kinds  of  organizational  situations  or 
changes  that  must  be  part  of  the  transition 
to  VISTA. 

Personnel  will  be  unfamiliar  with 
VISTA  and  what  is  required  to  reengineer 
the  processes  they  enact  during  system 


acquisition.  Mutually  respected  collabo¬ 
rative  education,  elicitation,  and  informa¬ 
tion  sharing  among  the  participating  user, 
development  contractor,  and  program 
management  organizations  will  be  re¬ 
quired.  WWW-based  collaborative  work 
environments  or  acquisition  collabor- 
atories  (Kouzes,  Meyers,  and  Wulf,  1996) 
can  help  provide  the  information  infra¬ 
structure  needed  to  support  this.  But  par¬ 
ticipation  and  engagement  in 
reengineering  system  acquisition,  devel¬ 
opment,  and  program  management  must 
span  all  levels  of  the  organization  chart, 
and  must  achieve  commitment,  resources, 
and  strategic  attention  from  executive  and 
senior  management  in  order  to  increase 
the  likelihood  of  success  (Bashein, 
Markus,  and  Riley,  1994). 

Our  characterization  of  “as-is”  system 
acquisition  processes  and  practices,  as 
well  as  “to-be”  VISTA  based  approaches 
are  understated.  Clearly,  there  is  far  more 
detail  to  system  acquisition  or  virtual  sys¬ 
tem  acquisition  processes  and  practices 
than  can  be  described  here.  Furthermore, 
we  recognize  that  both  “as-is”  and  “to-be” 
approaches  to 
system  acquisi¬ 
tion  are  put  into 
practice  in  dif¬ 
ferent  ways,  in 
different  orga¬ 
nizational  set¬ 
tings,  for  differ¬ 
ent  system  ac¬ 
quisitions.  Cap¬ 
turing,  under¬ 
standing,  and  describing  these  variations 
requires  systematic  research,  empirical 
investigation,  and  wide-area  dissemina¬ 
tion.  However,  experience  has  shown 
that  this  attention  to  detail  can  lead  to 


"The  move  to  adopt, 
implement,  make 
routine,  and  repli¬ 
cate  the  VISTA  ap¬ 
proach  seems  to  be  a 
radical  departure 
from  current  system 
acquisition  practices 
and  processes." 
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distinguishing  what’s  common  from 
what’s  circumstantial.  Such  detail  will 
help  surface  specific  actions  to  take  to  suc¬ 
cessfully  engage  personnel  to  collahora- 
tive  identify  and  perform  the  organiza¬ 
tional  transformations  needed  to  transition 
from  the  “as-is”  to  the  “to-he.” 

Next,  as  the  world  moves  towards  a  glo¬ 
bally  networked  information  infrastructure 
based  on  the  Internet  and  WWW,  we  rec¬ 
ognize  that  the  information  systems  and 
computer-based  tools  supporting  the  ac¬ 
quisition,  development,  and  program 
management  will  increasingly  become 
heterogeneous  relative  to  one  another 
(Noll  and  Scacchi,  1991;  Scacchi  and 
Noll,  1997).  Interoperability  will  not  be 

easily  achieved 
without  the  ex¬ 
perience  and 
expertise 
needed  to  make 
it  happen.  How¬ 
ever,  new  infor¬ 
mation  tech¬ 
nologies  are 
rapidly  emerg¬ 
ing  that  will 
give  rise  to  new 
ways  to  more 
rapidly  config¬ 
ure,  intercon¬ 
nect,  and  inte¬ 
grate  software 
systems  in  order 
to  enable  them 
to  interoperate.  Furthermore,  what’s  likely 
to  be  critical  during  early  VISTA-based 
acquisition  and  development  cycles  is  re¬ 
alizing  interoperability  at  the  organiza¬ 
tional  process  level,  rather  than  only  at  the 
traditional  system  function  level.  Experi¬ 
ence  shows  that  addressing  and  resolving 


interoperability  between  distinct  organi¬ 
zations,  such  as  those  participating  in  a 
system  acquisition,  can  often  lead  to  ways 
to  obviate,  minimize,  or  avoid  system 
function  interoperability  dependencies 
(STSC,  1995).  This  helps  to  refine,  stream¬ 
line,  and  focus  both  system  architecture  and 
system  development  processes. 

Last,  as  indicated  earlier,  attention  in 
this  article  is  directed  at  emphasizing  the 
re-tooling  and  reengineering  system  ac¬ 
quisition  processes  and  system  feasibility 
assessment.  However,  a  greater  payoff  can 
potentially  result  from  complementary 
incorporation  of  process  reengineering 
concepts,  techniques,  and  tools  into 
VISTA  approaches  (Nissen,  1997;  Scacchi 
and  Mi,  1997;  Scacchi  and  Noll,  1997; 
Scacchi,  et  ah,  1997).  For  example,  recent 
efforts  to  redesign  acquisition  and  procure¬ 
ment  processes  for  the  Navy  have  identi¬ 
fied  a  number  of  ways  these  processes  can 
be  transformed  and  streamlined  to  realize 
substantial  reduction  in  cycle  times  and 
administrative  costs  (Nissen,  1997; 
Scacchi,  et  al.,  1997).  But  these  capabili¬ 
ties  have  not  been  used  to  support  the  ac¬ 
quisition  of  large  software  systems  and 
thus  require  further  investigation.  None¬ 
theless,  the  vision  of  a  21st  century  “digi¬ 
tal  government”  raises  such  matters  for 
systematic  acquisition  research  and  em¬ 
pirical  investigation  befitting  a  grand  chal¬ 
lenge  to  the  academic,  industrial,  and  gov¬ 
ernment  research  community  (Schorr  and 
Stolfo,  1997).  Subsequently,  the  acquisi¬ 
tion  community  needs  to  stimulate  re¬ 
search  that  can  find  new  ways  to  radically 
streamline  program  operations,  reduce 
system  costs,  and  improve  service  quality 
through  reengineering,  reinvention,  and 
systematic  utilization  of  emerging  infor¬ 
mation  technologies  and  infrastructures. 


"Next,  as  the  world 
moves  towards  a 
globally  networked 
information  infra¬ 
structure  based  on 
the  I nternet  and 
WWW,  we  recognize 
that  the  information 
systems  and  com¬ 
puter-based  tools 
supporting  the 
acquisition,  develop 
ment,  and  program 
management  will 
increasingly  become 
heterogeneous 
relative  to  one 
another." 
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Odnclusions 


We  have  identified  opportunities  for 
research  and  application  of  modeling, 
simulation,  and  evolutionary  development 
technologies  to  re-tooling  and  reengi¬ 
neering  system  acquisition  processes. 
These  tools  and  techniques  can  help  to 
analyze  overall  feasibility  and  risks  at  vari¬ 
ous  points  in  the  system  acquisition  life 
cycle.  Such  a  capahility  offers  the  poten¬ 
tial  to  reduce  software  system  acquisition 
risks  and  avoidable  costs,  as  well  as  ex¬ 
plore  alternative  system  options  in  order 
to  develop  more  affordable,  capable,  and 
flexible  systems.  Subsequently,  we  use  the 
new  SC-21  battleship  program  as  a  case 
study  to  help  illustrate  and  explain  how 
virtual  system  acquisition  can  work. 

We  put  forward  a  vision  and  approach 
for  how  to  rethink  the  manner  in  which 
software-intensive  systems  can  be  ac¬ 
quired  across  the  acquisition  life  cycle. 
Central  to  this  vision  is  a  new  approach  to 
virtual  system  acquisition  we  call  VISTA. 
We  believe  that  VISTA  offers  a  new  strat¬ 
egy  for  how  to  address,  resolve,  or  miti¬ 
gate  the  recurring  problems  that  accom¬ 
panies  complex  system  acquisition.  Ma¬ 
jor  program  acquisitions  such  as  the  SC- 
21  class  of  ships,  the  Joint  Strike  Fighter, 
and  others  are  positioned  to  take  advan¬ 
tage  of  timely  investment  and  adoption  of 
VISTA  strategies  and  support  environ¬ 
ments. 

VISTA  is  a  new  approach  to  the  acqui¬ 
sition  of  software-intensive  systems.  It 
seeks  to  build  on  knowledge  of  best  prac¬ 
tices  in  “as-is”  acquisition  and  develop¬ 
ment  processes,  as  well  as  moving  toward 
a  re-tooled  and  reengineered  “to-be”  soft¬ 
ware  systems  acquisition  and  develop¬ 
ment  process.  The  acquisition  of  complex 


systems  such  as  the  SC-21  class  of  ships 
will  use  virtual  prototyping  and  manufac¬ 
turing  tools  to  acquire  and  build  virtual 
ships  using  col- 
laborative 
wide-area  com¬ 
puter-based  en¬ 
vironments . 

Flowever,  mod¬ 
eling  and  simu¬ 
lation  tools  and 
techniques  have 
not  yet  been 
proposed  to 
support  the  ac¬ 
quisition  and 
development  of 
the  software  systems  needed  to  make  the 
overall  ship  system  operational  and  effec¬ 
tive.  Thus,  we  propose  to  fill  this  gap  with 
the  VISTA  approach. 

We  believe  that  tools,  techniques,  and 
concepts  embodied  in  the  VISTA  approach 
merit  consideration  and  application  in 
forthcoming  large-scale  system  acquisi¬ 
tions.  These  include  incremental  acquisi¬ 
tion  interleaved  with  development,  virtual 
prototyping,  wide-area  collaboratories, 
and  software  requirement  negotiation  and 
validation  environments.  However,  it 
would  be  misleading  to  indicate  that  they 
are  being  used  together  in  the  manner  we 
suggest.  The  VISTA  approach  needs  to  be 
experimentally  applied  and  refined.  Ac¬ 
cordingly,  a  research  and  development 
technology  road  map  was  presented  that 
lays  out  a  path  for  the  iterative,  incremen¬ 
tal  evolution  and  integration  of  the  tech¬ 
nologies  needed  to  support  the  VISTA  vi¬ 
sion.  The  technologies  needed  to  support 
the  VISTA  approach  need  to  be  brought 
together  and  made  accessible  to  different 
acquisition  participants. 


"[VISTA]  seeks  to 
build  on  knowledge 
of  best  practices  in 
"as-is"  acquisition 
and  development 
processes,  as  well  as 
moving  toward  a 
re-tooled  and 
reengineered 
"to-be"  software 
systems  acquisition 
and  development 
process." 
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The  VISTA  approach  we  present  is  a 
vision  of  how  the  acquisition  of  software¬ 
intensive  systems  can  he  designed  and 
streamlined  for  use  in  the  years  ahead. 
Major  system  acquisition  programs  such 
as  the  SC-21  battleships  or  Joint  Strike 
Fighter  aircraft  are  representative  candi¬ 
dates  for  the  VISTA  approach.  The  suc¬ 
cess  of  programs  such  as  these  will  de¬ 
pend  in  part  on  the  successful  acquisition 
and  development  of  the  software  systems 
that  enable  these  platforms  to  do  their  job. 
VISTA  represents  a  substantial  department 
from,  and  alternative  to,  present  software 
system  acquisition  practices  (STSC,  1995; 
SPMN,  1997).  Nonetheless,  we  have  cast 
it  in  a  manner  that  shows  how  to  incre¬ 
mentally  transition  from  the  technology 


and  organizational  practices  that  today 
support  software  system  acquisition  to  the 
VISTA  approach  we  envision. 

Finally,  moving  to  adopt  and  practice 
VISTA-based  system  acquisitions  is  not 
without  its  risks.  Accordingly,  we  have 
sought  to  identify  the  technological  and 
organizational  transitions  that  must  be  re¬ 
searched,  modeled,  and  simulated  to  help 
reduce  the  risks  and  improve  our  under¬ 
standing  of  how  to  evolve  system  acqui¬ 
sition  practices  and  support  environments 
to  help  see  the  way  to  VISTA.  In  this 
sense,  the  VISTA  approach  could  be  dem¬ 
onstrated  by  applying  it  to  the  acquisition 
and  development  of  a  software  system  that 
incorporates  the  concepts  in  this  paper  and 
related  reports  (Boehm  and  Scacchi,  1996). 
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